The
Hping2 idle Host Scan
Erik J. Karmeling
February 26, 2001
Traduit de l’anglais par
dzeta (dzeta@netcourrier.com)
NdT : Ce texte demande pour
pouvoir être compris clairement et sans amalgame, une bonne connaissance de l’IP
spoofing et plus particulièrement du blind-spoofing (aucune de ces techniques ne
sont décrites dans ce texte et si vous ne les connaissez vous risquez de vous
mélanger) et également des connaissances basiques de la suite de protocole
TCP/IP. Certains mots n’ont volontairement pas été traduits ainsi que les
titres. Pour toute question, que ce soit pour des mots anglais que vous ne
comprenez pas, ou sur le texte en général, n’hésitez pas à m’envoyer un
mail.
Introduction
J’ai lu récemment un article
scientifique américain au sujet de la recherche sur les nouvelles planètes. Il
résumait la difficulté des astronomes a déterminer si une étoile avait des
planètes en orbites. Ces difficultés résultaient des longues distances, des
limitations technologiques, et du fait que les planètes émettent très peu de
lumières. Inévitablement, les scientifiques ont réalisé qu’ils avaient besoin
d’une nouvelle méthode pour détecter la présence de planètes à l’extérieur de
notre propre système solaire.
La détection de planète
Doppler est la méthode qui fût élaborée. En utilisant cette méthode, les
astronomes analyse les variations dans la lumière étant émis par une étoile. Si
la lumière semble se déplacer du bleu vers la section rouge du spectre, il y a
possibilité qu’un corps planétaire soit en orbite autour de l’étoile. Une
planète va exercer une certaine influence gravitationnelle sur une étoile, ce
qui fait que l’étoile, et la lumière qu’elle émet, vont faire des va-et-vient
ainsi qu’un fort tremblement. C’est une méthode de détection assez ingénieuse,
et à prouvé son importance dans l’astronomie moderne.
La chose qui m’intéresse
réellement au sujet de cet article était le fait que les scientifiques pouvait
déterminer les caractéristiques d’une planète avec une large certitude, sans
avoir réellement pu voir la planète elle même. La masse d’un corps en orbite et
sa distance par rapport au soleil, peut être déterminée en analysant l’impact
qu’elle a sur l’étoile, laquelle est en orbite. J’ai trouvé ce type d’analyse
assez intéressant, et était surpris de trouver qu’il y avait une méthode
d’analyse théoriquement équivalente dans la communauté des pirates
informatiques. Il y a une méthode de détermination des caractéristiques d’un
ordinateur cible, en analysant le comportement d’une troisième partie, et
l’effet que la cible a dessus. C’est ce que l’on appelle l’idle host scanning.
Bien que beaucoup plus simple à comprendre que la détection de planète Doppler,
en son sein, cette méthode est en
effet très similaire.
Overview
of Idle Host Scanning
Laissez-moi commencer par
vous donner une brève explication de l’idle host scanning. C’est une
intelligente combinaison de différentes techniques d’informations assemblées,
qui sont en gros utilisés sur l’Internet aujourd’hui. Cela combine l’IP spoofing
et réseau, ou host scanning, dans une manière efficace d’opérer un sondage
anonyme sur des services. Ceci est similaire en plusieurs points à la méthode
scientifique décrite plus haut, et est encore mieux décrit en construisant une
comparaison directe entre les astronomes, et ceux qui voudraient utiliser un
idle host scan : l’objet désiré des astronomes est la découverte d’une planète
invisible, celui du pirate, la découverte d’un hôte connecté. Le scientifique va
opérer une analyse directe des propriétés de la lumière de l’étoile dans le but
de glaner des informations sur les planètes en orbites. Un pirate va analyser le
comportement de l’idle host dans le but de trouver des informations sur la
cible. Les deux méthodes, à cause de la nature indirecte des informations
techniques assemblées, vont main dans la main.
Comme avec tout type de
scan, la partie attaquante à le désir de rassembler des informations sur les
caractéristiques du réseau, ou sur des ordinateurs connectés à internet.
L’information peut être ce que les services de l’hôte offre, sur quels ports ces
services tournent, ou encore le système d’exploitation de la cible. Typiquement,
de tels scans sont précurseurs d’autres sondages beaucoup plus conséquent ou
d’une attaque totale. L’attrait d’un idle host scan pour le pirate, est qu’un
scan de ce type peut être accompli de façon anonyme.
Ceci nous amène à la
véritable nature insidieuse de cette méthode de scan. Avec le relatif anonymat
qui peut être maintenu pendant l’utilisation de cette méthode, à travers
l’utilisation d’un troisième ordinateur ne se doutant de rien, ce type de
sondage de réseau est très difficile a tracer. En effet, retrouver l’attaquant
pour l’administrateur réseau relève du haut vol : non seulement il aura besoin
de contacter l’innocente troisième partie, mais les logs devront être aussi
comparés, dans l’espoir que la véritable origine du scan puisse être révélé.
Vous pouvez juste espérez que l’adresse d’origine n’était pas celle d’un système
compromis, que le pirate ai utilisé comme plate-forme de lancement. Ce type de
scan pose une menace définitive pour les réseaux et ordinateurs reliés au net,
et offre une prometteuse méthode de rassemblement d’information de façon anonyme
pour les pirates.
Breakdown
of the scan
Un petit réseau témoin à été
employé pour recueillir des informations pour cet article. Ce qui suit est
l’information sur les hôtes impliqués, et l’ordre par lequel l’attaque
d’échantillon à eu lieu. Cette information sont le cassage du concept d’idle
host scan et n’inclut pas les détails spécifiques. La partie de ce document
traite a l’aide d’Hping ce type de scan a un niveau beaucoup plus élevé.
| Serveur pirate | Idle serveur | Serveur cible | |
| OS | Red hat linux 6.2 | Windows NT 4 SP | Windows 98 |
| IP adresse | 192.168.0.4 | 192.168.0.5 | 192.168.0.6 |
Etape 1. La première étape pour le
pirate est d’envoyer à l’idle host des paquets avec aucun flag de configuré, au
port 0. Typiquement, ce type de paquet va nous mettre dans l’attente d’un RST de
la part de l’idle host.
Attaquant
>>>> packet
>>>>
Idle host
192.168.0.4
192.168.0.5
Etape 2. La deuxième phase dans cette
attaque se produit quand l’Idle host
reconnaît les paquets avec un RST attaché pour l’attaquant.
Attaquant
<<<< RST
<<<<
Idle host
192.168.0.4
192.168.0.5
Etape 3. Dans la troisième partie de
l’attaque, l’attaquant envoie des paquets SYN spoofés à la cible, avec l’adresse
original spécifiquement ouvrée comme Idle host.
Attacker
>>>> SYN (spoofed as
192.168.0.5) >>>>
cible
192.168.0.4
192.168.0.6
Etape 4. Une fois que la cible à
répondus aux paquets spoofés, et envoyés la réponse à l’idle host, la quatrième
phase est complète.
Idle
host
<<<< ACK <<<<
cible
192.168.0.5
192.168.0.6
Etape 5. La cinquième étape dans ce
scan est la plus complexe. Avec la session continuant de tourner de l’attaquant
vers l’idle host, l’attaquant espère voir le reflet des ISN ( initial sequence
number) dans les paquets RST que
l’idle host renvoie. Ceci impliquerait que l’idle host envoie des paquets RST à
la cible pour un ACK inattendu (NdT :il n’y a pas d’ACK dans des paquets RST).
Ces paquets RST vont augmenter leurs ISN, donc augmenter les ISN dans les
paquets RST que l’idle host envoie a l’attaquant.
Idle host
>>> RST (séq de num est effectuée) >>>
cible 192.168.0.5
192.168.0.6
V
V
RST(évidence d’activité par
des ISN artificiellement gonflés)
V
V
V
Attaquant
192.168.0.4
Du point de vue de
l’attaquant, cet exemple de scan est hautement réussi. On le reflète dans le
fait que la génération d’ISN de l’idle host a l’attaquant a été affecté.
L’attaquant saurait à ce moment, que la cible répondait à des paquets SYN
spoofés, envoyés à un port particulier. Ceci signifierait que la cible offre un
service sur ce port.
Cette méthode de scan dépend
lourdement d’une des caractéristiques de l’idle host. Cette caractéristique
étant, une prédiction du schéma des numéros de séquence générés. IHS (idle host
scanning) dépend de l’analyse de l’activité à un niveau du paquet, et utilises
le numéro de sequence IP comme référence. Il serait pratiquement impossible de
mesurer le niveau d’activité d’un serveur si il produisait de véritable numéro
de séquence randomizés, indépendamment du niveau d’activité.
En 1989, Steven Bellovin a
tracé les grandes lignes du danger des numéros de séquence prévisible, dans son
article « Security problems in the TCP/IP protocole suite ». Etant donné le
temps qui a passé depuis la parution de cette article, il est intéressant de
noter qu’il existe toujours des systèmes d’exploitation qui montrent ce
comportement. J’aimerais préciser que cette importante faille de sécurité, qui
dépendait de cette caractéristique,
se sont produits dans le passé. L’attaque de Kevin Mitnick-Tsutomu Shimomura en
reste le meilleur exemple.
Enter Hping
Hping est une application
développé par Salvatore SanFilippo, un programmeur italien. Il est aussi connu
sous le nom Antirez. Mr SanFilippo est accrédité de la découverte et du
développement de cette méthode de scan . Cette découverte à été retracée dans un post fait sur
bugtrap le 18 décembre 1998. Une copie de l’ensemble du document est disponible
à <http://www.kyuzz.org/antirez/papers/dumbscan.html>
Comme son nom l’indique,
Hping est un programme pour exécuter un type de ping. D’après les propres mots
de Salvatore SanFilippo, Hping est
un logiciel pour l’audition de pile TCP/IP, découvrir les rules d’un firewall,
scanner le port TCP dans de nombreux modes, transférés des fichiers à travers un
firewall et beaucoup d’autres choses. Bien que Hping ait la capacité d’utiliser
le protocole ICMP comme pour un ping conventionnel, ce texte traitera uniquement
d’Hping sur le protocole TCP. Hping à la capacité de délivrer un paquet, ou des
paquets, sur les protocoles les plus communément utilisés aujourd’hui.
Hping est un soft GPL qui
tourne sous GNU/linux, FreeBSD, and OpenBSD, aussi bien que sur d’autres
systèmes d’exploitation. L’url pour Hping est <http://www.kyuzz.org/antirez/hping>. Le
code source de cette application est inclue dans le package.
Ce document n’est pas une
analyse d’Hping, mais plutôt de regarder la manière dont un Idle host scan peut
être accompli avec Hping. Ce n’est pas seulement un outil d’Idle host scanning,
mais aussi un outil très utile à
l’administration de réseau. Pour ceux qui sont intéressés par la grande variété
de fonctions que Hping supporte vous êtes
encouragés à lire la documentation qui vient avec le code source.
Bien que mon expérience avec
Hping soit assez limitées aux scan test suivant, je suis convaincu de sa
souplesse comme outil d’administrateur réseau. Quelques exemples seraient le
test des rules d’un firewall, évaluation de vulnérabilité, et d’autres tâches de
sécurité associé au réseau. Hping a transformé sa voie dans la collection des ports
FreeBSD, ce qui indiqueraient qu’un certain nombre de gens l’utilise a des fins
administratives. Malheureusement, l’état de la question dans la sécurité de
l’information aujourd’hui, est que les outils les plus puissants disponible
gratuitement sont utilisés aussi bien a but légitime qu’a but malfaisant.
Inutile de dire qu’Hping est un puissant outil d’attaque.
The
Hping Idle Host Scan
Les informations suivantes
sont une copie directe d’un Hping idle host scan, réalisée sur un réseau
d’essai. Dans le but de fournir une meilleure compréhension aux données qui
suivent, j’ai inclus la définition des switchs utilisés par Hping dans ce type
de scan particulier. Un texte complet des options Hping est disponible avec la
documentation de Hping.
Une autre chose a noter est
que ce type de balayage est plus facilement accompli avec X-Windows, ou 2
sessions Hping peuvent être lancé sur le même bureau. 2 sessions Hping peuvent
être lancés simultanément : ceci est due au fait que dans la même tranche de
temps, le pirate peut utiliser Hping pour surveiller un hôte, alors qu’il envoie
des paquets spoofés a un autre.
Ces informations sont
directement copiées depuis le répertoire d’aide d’Hping. N’importe quelle
information de la documentation, ou n’importe quel output directe d’Hping
lui-même est intentionnellement laissé dans sa forme originale.
usage:
hping host [options]
-r
--rel relativize id field (to estimate host traffic)
-W
--winid use win* id byte ordering
-a
--spoof spoof source address
-S
--syn set SYN flag
-p
--destport [+][+] destination port(default 0) ctrl+z inc/dec
Les données suivantes
partent de la perspective d’ une partie attaquante dans un idle host scanning.
Cela montrera non seulement le point de vue du pirate dans cette attaque, mais
aussi de quelle manière cette attaque apparaît sur la machine cible. Il faut
noter que la cible est protégée par un host-based firewall.
Ci-dessous est présenté la
première étape dans l’attaque, l’initiation d’une session Hping avec l’idle
host.
[root@test
sbin]# ./hping 192.168.0.5 -r
eth0
default routing interface selected (according to /proc)
HPING
192.168.0.5 (eth0 192.168.0.5): NO FLAGS are set,
40 headers + 0 data bytes
46
bytes from 192.168.0.5: flags=RA seq=0 ttl=128 id=6416 win=0 rtt=0.3 ms
46
bytes from 192.168.0.5: flags=RA seq=1 ttl=128 id=+256 win=0 rtt=0.2 ms
46
bytes from 192.168.0.5: flags=RA seq=2 ttl=128 id=+256 win=0 rtt=0.2 ms
46
bytes from 192.168.0.5: flags=RA seq=3 ttl=128 id=+256 win=0 rtt=0.2 ms
46
bytes from 192.168.0.5: flags=RA seq=4 ttl=128 id=+256 win=0 rtt=0.3 ms
---
192.168.0.5 hping statistic ---
5
packets tramitted, 5 packets received, 0% packet loss
round-trip
min/avg/max = 0.2/0.2/0.3 ms
Comme on peut l’observer,
l’output depuis la plus simple commande Hping est très similaire aux output ICMP
conventionnel. Le commutateur -r est utilisé dans cette connexion initiale, qui
dialogue avec Hping pour ne montrer qu’a l’attaquant, la difference qu’il y a
dans le champ id. Ainsi, par opposition
a la visualisation de la totalité du scan, parfois dur pour contrôler la
valeur d’identification, Hping nous montre seulement la différence dans ce
champ.
Il y a deux points
importants a mentionner ici. Le premier étant, celui du début du processus de
détermination d’un hote idle, ou actif. En analysant le champ id, l’attaquant
peut dire si l’hôte envoie des paquets vers et depuis internet. Si la valeur du
champ id change fréquemment, et non d’une façon prévisible, l’attaquant
supposera que l’hôte en question effectue des échanges de paquets. Si la
génération d’id de l’hôte est très active, l’hôte devrait être inapproprié pour
ce type de scan. L’output au-dessus, nous montre toutefois que nous avons un
hôte véritablement inactif. Ceci nous fait un candidat principal comme tiers
dans ce balayage. S’il vous plait, gardez a l’esprit que n’importe quel
dispositif relié a l’Internet avec une pile TCP/IP peut être utilisé de cette
manière Ceci inclut les stations de travail, imprimantes et les routeurs, pour
n’en nommer que quelques uns.
Le second point est que la
valeur dans le champ id, augmente d’un standard + 256 pour chaque paquets
envoyés. Selon la documentation Hping, Ceci est un indicateur d’un hôte windows.
Hping s’est déjà prouvé comme un outil de rassemblement d’information valable,
puisque l’attaquant a déjà déterminé que l’idle host utilisait un système
d’exploitation microsoft.
Les output ci-dessous, sont
exactement les mêmes que la session Hping, mais avec le switch -W utilisé but de compenser le comportement +256 de
windows. Remarquez la différence dans les output suivant, causés par l’option
-W.
[root@test
sbin]# ./hping 192.168.0.5 -r -W
eth0
default routing interface selected (according to /proc)
HPING
192.168.0.5 (eth0 192.168.0.5): NO FLAGS are set,
40 headers + 0 data bytes
46
bytes from 192.168.0.5: flags=RA seq=0 ttl=128 id=4126 win=0 rtt=0.4 ms
46
bytes from 192.168.0.5: flags=RA seq=1 ttl=128 id=+1 win=0 rtt=0.2 ms
46
bytes from 192.168.0.5: flags=RA seq=2 ttl=128 id=+1 win=0 rtt=0.2 ms
46
bytes from 192.168.0.5: flags=RA seq=3 ttl=128 id=+1 win=0 rtt=0.2 ms
46
bytes from 192.168.0.5: flags=RA seq=4 ttl=128 id=+1 win=0 rtt=0.3 ms
46
bytes from 192.168.0.5: flags=RA seq=5 ttl=128 id=+1 win=0 rtt=0.2 ms
46
bytes from 192.168.0.5: flags=RA seq=6 ttl=128 id=+1 win=0 rtt=0.2 ms
---
192.168.0.5 hping statistic ---
7
packets tramitted, 7 packets received, 0% packet loss
round-trip
min/avg/max = 0.2/0.3/0.4 ms
Il est plus facile de
manipuler les données ci-dessus que
les précédentes, parce que le champ id a été maintenant normalisé avec la
compensation pour les comportements MS-windows +256. En observant les champs id,
l’attaquant peut déterminer si l’hôte est en train d’envoyer des paquets. En
conséquence, le pirate serait capable de tirer la conclusion depuis les données
ci-dessus, que cette hôte idle. Supposant que l’attaquant a déjà obtenu
l’adresse IP de la cible destinée, il peut procéder ainsi a l’idle host
scan.
Ce qui suit est l’output
d’un pirate envoyant des paquets SYN spoofés a un hôte cible. L’adresse
originelle spoofées est celle de l’idle Windows NT hôte comme définit plus tôt.
La cible est un hôte windows 98 qui n’offre aucun service sauf http¨sur le port
80. Gardez a l ‘esprit que l’attaquant ne connaît pas ceci et enverra
premièrement des paquets FTP sur le port 21.
[root@test
sbin]# ./hping -a 192.168.0.5 -S -p 21 192.168.0.6
eth0
default routing interface selected (according to /proc)
HPING
192.168.0.6 (eth0 192.168.0.6): S set, 40 headers + 0 data bytes
---
192.168.0.6 hping statistic ---
8
packets tramitted, 0 packets received, 100% packet loss
round-trip
min/avg/max = 0.0/0.0/0.0 ms
Vous aurez remarqué que 100%
des paquets sont perdus ici, la troisième étape dans l’attaque. La raison de
ceci est évidente. Quand la partie effectuant le scan envoie des paquets spoofés
avec l’adresse originelle a la station Windows NT, la réponse de la machine
Windows 98 sera pour l’idle host. Ceci causerait la perte totale des paquets, du
coté de l’attaquant. Cependant, en mettant a jour sa session de surveillance
initiale avec l’hôte windows NT, il n’a pas perdu la capacité de voir l’impact
des ses paquets SYN spoofés.
Ici donc, nous sommes en présence d’un tournant dans un idle
host scanning. Si l’attaquant a une session Hping continue avec l’idle host,
l’attaquant devrait être capable de déterminer si la cible a envoyé des paquets
comme réponse, a l’idle host, en surveillant les valeurs dans le champ id de
l’output Hping. Ci-dessous est décrit l’output depuis une session idle host avec
la station de travail Windows NT. Si il y avait un changement marqué dans les
valeurs id, l’attaquant supposerai que le service FTP¨est disponible.
[root@test
sbin]# ./hping 192.168.0.5 -r -W
eth0
default routing interface selected (according to /proc)
HPING
192.168.0.5 (eth0 192.168.0.5): NO FLAGS are set,
40 headers + 0 data bytes
46
bytes from 192.168.0.5: flags=RA seq=0 ttl=128 id=4141 win=0 rtt=0.4 ms
46
bytes from 192.168.0.5: flags=RA seq=1 ttl=128 id=+1 win=0 rtt=0.3 ms
46
bytes from 192.168.0.5: flags=RA seq=2 ttl=128 id=+1 win=0 rtt=0.2 ms
46
bytes from 192.168.0.5: flags=RA seq=3 ttl=128 id=+1 win=0 rtt=0.3 ms
46
bytes from 192.168.0.5: flags=RA seq=4 ttl=128 id=+1 win=0 rtt=0.2 ms
46
bytes from 192.168.0.5: flags=RA seq=5 ttl=128 id=+1 win=0 rtt=0.2 ms
46
bytes from 192.168.0.5: flags=RA seq=6 ttl=128 id=+1 win=0 rtt=0.2 ms
46
bytes from 192.168.0.5: flags=RA seq=7 ttl=128 id=+1 win=0 rtt=0.2 ms
46
bytes from 192.168.0.5: flags=RA seq=8 ttl=128 id=+1 win=0 rtt=0.2 ms
---
192.168.0.5 hping statistic ---
9
packets tramitted, 9 packets received, 0% packet loss
round-trip
min/avg/max = 0.2/0.3/0.4 ms
Veuillez noter que la valeur
id ne change pas dans cette session Hping avec l’idle host. Considérant que les
valeurs sont restées uniformes pour la tranche de temps données que les paquets
spoofés ont été envoyés, on pourrait supposer que l’hôte windows 98 n’offre pas
de services FTP. Si l’hote cible offre des services FTP sur le port 21, la
transaction se serait déroulait comme suit.
· La cible aurait du recevoir
les paquets SYN spoofés.
· Il aurait ainsi répondu aux
paquets avec une limite SYN/ACK
pour le NT idle host.
· L’hôte windows NT aurait
ainsi reçu des paquets SYN|ACK, et répond convenablement avec un RST, car il n’a
pas fait de demande FTP.
Si ceci était le cas, la
génération des paquets RST auraient changées les valeurs dans le schéma de
numérotation id de l’hote. Puisque ce n’était pas le cas selon les données
précédentes, le pirate peut supposer que le service FTP n’est pas disponible sur
la cible Windows 98.
Afin de fournir des
informations détaillées sur ce qu’un scan Hping spoofés sur un service
indisponible ressemble depuis le point de vue de la cible, regardez les
informations suivantes. Ce log a été obtenu par ZoneAlarm, un host-based
firewall disponible gratuitement, pour windows. Souvenez-vous, le seul service
qu’une machine Windows 98 offre, est http sur le port 80. Le firewall est
configuré pour stopper les requêtes, pour tous les ports autres que le 80. Ceci
devrait être reflété dans l’output log suivant, qui montre le traffic refusé sur
la cible.
ZoneAlarm
Basic Logging Client v2.1.44
Windows
98-4.10.2222- A -SP
type,date,time,source,destination,transport
FWIN,2001/01/30,14:12:10
-5:00 GMT,192.168.0.5:3014,192.168.0.6:21,TCP
FWIN,2001/01/30,14:12:12
-5:00 GMT,192.168.0.5:3015,192.168.0.6:21,TCP
FWIN,2001/01/30,14:12:12
-5:00 GMT,192.168.0.5:3016,192.168.0.6:21,TCP
FWIN,2001/01/30,14:12:14
-5:00 GMT,192.168.0.5:3017,192.168.0.6:21,TCP
FWIN,2001/01/30,14:12:14
-5:00 GMT,192.168.0.5:3018,192.168.0.6:21,TCP
FWIN,2001/01/30,14:12:16
-5:00 GMT,192.168.0.5:3019,192.168.0.6:21,TCP
FWIN,2001/01/30,14:12:16
-5:00 GMT,192.168.0.5:3020,192.168.0.6:21,TCP
FWIN,2001/01/30,14:12:18
-5:00 GMT,192.168.0.5:3021,192.168.0.6:21,TCP
Ces informations expliquent
pourquoi il n’y avait aucun changement marqué de valeur id, de la part de la
station de travail Windows NT. Le firewall sur cet ordinateur refuse le trafic
d’arrivée sur le service FTP. Or l’intérêt est que l’adresse originale pour la
requête FTP est révèle dans le log ci-dessus, comme l’adresse de l’idle host, et
non de la partie attaquante. En faisant confiance aveuglément aux logs de cette
machine, l’administrateur de cet ordinateur peut potentiellement accusé une
mauvaise personne de scanner leur FTP.
L’output suivant va refléter
un Hping idle host scan, qui est réussi dans le sens ou la cible montre qu’elle
a un service disponible en répondant a l’idle host. Le pirate peut, avec
confiance, supposer que la cible offre un service sur le port 80, si il a obtenu
cet output.
L’attaquant envoie des
paquets SYN spoofés au port 80 de la cible. *
[root@test
sbin]# ./hping -a 192.168.0.5 -S -p 80 192.168.0.6
eth0
default routing interface selected (according to /proc)
HPING
192.168.0.6 (eth0 192.168.0.6): S set, 40 headers + 0 data bytes
---
192.168.0.6 hping statistic ---
7
packets tramitted, 0 packets received, 100% packet loss
round-trip
min/avg/max = 0.0/0.0/0.0 ms
En attendant, l’attaquant
avait surveillé l’idle host avec une autre session Hping.
root@test
sbin]# ./hping 192.168.0.5 -r -W
eth0
default routing interface selected (according to /proc)
HPING
192.168.0.5 (eth0 192.168.0.5): NO FLAGS are set,
40 headers + 0 data bytes
46
bytes from 192.168.0.5: flags=RA seq=0 ttl=128 id=4170 win=0 rtt=0.3 ms
46
bytes from 192.168.0.5: flags=RA seq=1 ttl=128 id=+1 win=0 rtt=0.2 ms
46
bytes from 192.168.0.5: flags=RA seq=2 ttl=128 id=+1 win=0 rtt=0.2 ms
46
bytes from 192.168.0.5: flags=RA seq=3 ttl=128 id=+1 win=0 rtt=0.3 ms
46
bytes from 192.168.0.5: flags=RA seq=4 ttl=128 id=+2 win=0 rtt=0.2 ms
46
bytes from 192.168.0.5: flags=RA seq=5 ttl=128 id=+2 win=0 rtt=0.2 ms
46
bytes from 192.168.0.5: flags=RA seq=6 ttl=128 id=+2 win=0 rtt=0.2 ms
46
bytes from 192.168.0.5: flags=RA seq=7 ttl=128 id=+2 win=0 rtt=0.2 ms
46
bytes from 192.168.0.5: flags=RA seq=8 ttl=128 id=+2 win=0 rtt=0.2 ms
46
bytes from 192.168.0.5: flags=RA seq=9 ttl=128 id=+2 win=0 rtt=0.2 ms
46
bytes from 192.168.0.5: flags=RA seq=10 ttl=128 id=+2 win=0 rtt=0.3 ms
46
bytes from 192.168.0.5: flags=RA seq=11 ttl=128 id=+1 win=0 rtt=0.2 ms
46
bytes from 192.168.0.5: flags=RA seq=12 ttl=128 id=+1 win=0 rtt=0.2 ms
46
bytes from 192.168.0.5: flags=RA seq=13 ttl=128 id=+1 win=0 rtt=0.2 ms
46
bytes from 192.168.0.5: flags=RA seq=14 ttl=128 id=+1 win=0 rtt=0.2 ms
---
192.168.0.5 hping statistic ---
15
packets tramitted, 15 packets received, 0% packet loss
round-trip
min/avg/max = 0.2/0.2/0.3 ms
La chose la plus importante
a noter au sujet des données ci-dessus, est le changement dans le champ id de
l’idle host. Armés des informations ci-dessus, le pirate peut supposer que les 7
paquets SYN spoofés qui ont été envoyés a la cible, ont été reconnus avec 7
paquets ACK. Les paquets ACK ont été envoyés a l’idle host, qui en retour a
envoyé 7 paquets RST. Ces 7 paquets RST ont occupé les nombres id, qui ont été
reflété dans l’output de la session
de surveillance. Avec 7 paquets spoofés envoyés, et l’impact sur les valeurs id
de l’idle host etant approximativement de 7, les données sont fortement
révélatrice d’un service offert sur la cible. Le fait le plus intéressant, est
que le pirate, originairement 192.168.0.4, a simplement réussi a scanné la cible
192.168.0.6, anonymement tel que 192.168.0.5.
Comme toute méthode ou outil
pour le scan d’hôte ou de réseau, ceci peut être utilisé comme un outil de
réseau de mapping. Evidemment le manque de réaction dans les sequence id de
l’idle host devrait indiqué l’absence de service. Le service peut etre
firewalled, non disponible, ou configuré avec n’importe quel outil de la
troisième partie pour limiter sa connectivité. Ces données sont valables pour un
pirate, du fait qu’elles peuvent profiler des réseaux entier en cataloguant ce
qui n’est pas disponible, que ce soit des hôtes, ou des services.
Hping
advancement, and others tools.
Actuellement, la plus
récente version d’Hping, Hping2-beta54, a atteint la fin de sa vie. Salvatore
SanFilippo, et d’autres volontaires, recodent Hping du tout ou tout. Selon son
site Web, Hping3 sera nettement supérieur a l’actuel version. Il y aura des
améliorations d’installation, des outputs plus lisibles, et sera scriptable. Le
statut actuel du projet peut être suivi a : <http://www.kyuzz.org/antirez/hping3.html>
Hping n’est pas le seul
outil qui peut exécuter un idle host scan. « Idlescan » est un outil, qui à été
élaboré sur le concept d’un Hping idle host scan. Il a simplifié le concept de
l’utilisation d’idle host sur Internet, pour scanner des services. Il ne
comporte pas toutefois la large variété d’options qu’Hping possède, mais pour
les attaquants qui sont seulement intéressés dans l’exécution de ce type de
scan, cela fait un outil de scan tout prêt très tentant. Celui-ci est aussi un
programme disponible gratuitement, et l’url ou il peut être obtenu est dans la
section reference de ce document.
Common defense
Puisque l’idle host scanning
est une combinaison d’information rassemblant des techniques et méthodes de
piratage, défendre des réseaux de tels scans nécessite une approche multiple. La
défense pour une telle attaque devrait être cassé en 2 catégories différentes.
La première catégorie consiste aux niveaux des mécanismes de défense du serveur.
La seconde est au niveau de la défense du réseau. Le renforcement de la sécurité
au niveau serveur s’assurera qu’une machine sous votre extension administrative
ne puisse pas être utilisées comme une tierce partie dans ce type de scan. Au
niveau du réseau, vous vous assurez que l’idle host scanning ne provient pas de
votre réseau. En outre, des signatures de ce type de scan peuvent être alertées
au bon moment, et les traiter convenablement.
Defense
Section 1 - Host level
La prédiction de la
génération des numéros de sequences pour la part de l’idle host est l’une des
premières variables dans ce type d’attaque. Par conséquent, la randomization de
ces numéros devraient être une défense appropriées. Selon l’article précédemment
référence de Steven Bellovin’s, utilisant la cryptographie dans la génération
des numéros de sequence est une manière efficace de s’assurer que les numéros de
séquence sont véritablement aléatoires et non prévisible. Le meilleur exemple
est que ceci à déjà été implémenté dans OpenBSD, qui utilise un algorithme pour
modifier ses ISN quand il communique. En raison de ce perfectionnement de
sécurité, un ordinateur faisant tourner OpenBSD fait un idle host peu
attractif.
OpenBSD se tient seulement
comme exemple de la plupart des OS d’aujourd’hui, qui emploie aussi la
génération cryptographique des numéros de sequence, ou peut être patché pour
fonctionner ainsi. Avec les conditions ci-dessus, un serveur basé sur la
sécurité, gestion des logs, et un host-based firewall sont nécessaire dans le
but de s’assurer qu’un hôte n’est pas utilisé dans ce type de scan. Cela nous
amène a l’étape suivante dans la défense des systèmes contre ce type de scan,
l’implémentation de la sécurité network-based appropriée.
Defense
Section 2 - Network Level
Puisque l’ip spoofing est
une partie intégral de l’idle host scan, suivre les contre-mesures a l’IP
spoofing selon le CERT advisory CA-1995-01, est hautement conseillé. Ce qui est
énoncé :
« La meilleure méthode pour empêcher le problème de l’IP spoofing est
d’installer un routeur filtrant, qui restreint l’entrée a votre interface
externe ( connu comme l’ input filter) en refusant un paquet si il a une adresse
source de votre réseau interne. En outre, vous devriez filtrer les paquets
sortant qui ont une adresse source différente de votre réseau interne dans le
but d’empêcher une attaque d’IP source spoofing provenant de votre site. »
Les informations ci-dessus
fournit clairement les directives pour empêcher un idle scan extérieur depuis
votre réseau, qui pourtant semble faire défaut a fournir une explication sur la
façon de repousser les paquets spoofés entrants pour ce type de scan. Il est
probable que les paquets spoofés dans un scan de ce type proviennent de
l’Internet, et non pas de votre propre réseau. L’implémentation de filtres
entrant le fais toutefois ; combat de façon convaincante tout autres types d’IP
spoofing attaques. Quoiqu’il ne puisse durcir votre système contre un Idle host
scan, c’est une bonne idée d’utiliser cette contre-mesure.
Ceci nous amène a la section
suivante du conseil, qui tente une approche de solution, qui pourtant ne le
définit toujours pas complètement.
« Nous proposons que vous employez TCP wrappers pour autoriser l’accès
depuis seulement quelques machines sélectionnées. Bien que ce ne soit pas une
solution complète, cela réduit votre susceptibilité aux attaques.
Alternativement, changez la configuration de votre gateway Internet afin que
rlogin et rsh depuis l’Internet vers l’ (les) hôte(s) soient bloquées. Si ceci
n’est pas possible, désactivez les services rlogin et rsh sur tout vos hôtes.
»
L’utilisation de TCP
wrappers, et d’autres tiers outils, peuvent être une solution très
compréhensible pour se défendre contre beaucoup de types de scan et d’attaques
Je crois qu’une combinaison des pratiques fournira une solution acceptable pour
la défense network-based dans ce
scénario. La défense numéro 1 est le zèle de la part de l’administrateur. Ceci
inclus la lecture des logs, et la réponse aux scan et attaques avec les
procédures ultérieures appropriées. En somme, s’assurer que les systèmes sont a
jour avec des patches et hotfixes, est impératif.
L’implémentation d’un IDS
(intrusion detection system) au niveau du réseau a aussi son importance. Il y en
pas mal de commercial, et d’autres gratuits. Leurs capacités s’étendent de
l’analyse passive du traffic, a toutes les défenses actives possibles. Ceci sera
laissé comme un exercice pour le lecteur, pour décider quel IDS devrait fournir
une solution approprié pour votre environnement. Un bon point de départ pour
ceci : <http://www.sans.org/newlook/resources/IDFAQ/ID_FAQ.ht>
Puisque l’idle host scanning
est une combinaison de plusieurs différentes attaques, défendre un système
contre un tel type de scan peut être approché de multiples point de vue
différent. Dans une tentative de durcissement contre l’idle host scanning, les
systèmes et les administrateurs réseaux doivent être dynamique dans leurs choix
et implémentation de mesures défensives.
Conclusion
Certains défendent le fait
que le scan de réseau ne fait peu, voir aucun mal. En effet, d’un point de vue
scientifique, les astronomes utilisent des informations rassemblant différents
techniques, dans le but de rechercher des données d’une planète très éloignée.
Les pirates utilisent simplement des méthodes et procédures alternatives pour
rassembler des informations sur des ordinateurs, ceux qui les intéressent. Bien
sur, la différence primaire entre ces deux méthodes, est qu’une planète étant
étudiées depuis la terre, n’est pas sous la menace d’une attaque. Ce qui serait
le cas, si quelqu’un utilisant la procédure décrite ci-dessus devait scanner
votre réseau.
Dans les jours d’aujourd’hui
ou le constant changement des réseaux interconnectés, il est de plus en plus
difficile de maintenir la confidentialité, la disponibilité, et l’intégrité de
nos ressources informatiques. Ceci est particulièrement vrai dans un monde ou
les pirates trouvent constamment de nouveaux moyens de recueillir de
l’information, sonder, et attaquer nos réseaux. L’idle host scan, utilisant
Hping, comme défini dans ce document, n’est pas en soi une attaque active. C’est
une information, recueillant les techniques qui sont probablement utilisées
comme une manière anonyme de scanner nos réseaux, et dresser son intelligence
pour un assaut imminent.
References
[1]
Marcy, Jeffrey. Butler, Paul. "Giant Planets Orbiting Faraway Stars." Scientific
American, Volume 9, Number 1, 1998. March 1998.
URL: <http://www.sciam.com/1998/0398cosmos/0398marcy.html>
(February 12, 2001)
[2]
CERT Advisory CA-1995-01. "IP Spoofing Attacks and Hijacked Terminal
Connections." September 23, 1997.
URL: <http://www.cert.org/advisories/CA-1995-01.html>
(January 21, 2001)
[3]
CERT Advisory CA-1996-21. "TCP SYN Flooding and IP Spoofing Attacks." November
29, 2000.
URL: <http://www.cert.org/advisories/CA-1996-21.html>
(January 21, 2001)
4]
Securiteam. "A New Stealth Port Scanning Method." December 23, 1998.
URL:
<http://www.securiteam.com/securitynews/A_new_stealth_port_scanning_method.html>
(February 12, 2001)
5]
Bellovin, Steven M., "Security Problems in the TCP/IP Protocol Suite." Computer
Communications Review, 2:19, pp. 32-48, April 1989.
URL: <http://www.research.att.com/~smb/papers/ipext.ps>
(February 19, 2001)
6]
de Raadt, Theo. Hallqvist,
Niklas. Grabowski, Artur. Keromytis,
Angelos D.. Provos, Niels. "Cryptography in OpenBSD: An Overview." Usenix
1999.
URL: <http://www.openbsd.org/papers/crypt-paper.ps>
(February 19, 2001)
[7]
SanFilippo, Salvatore. "Original Bugtaq Posting." December 18, 1998.
URL:
<http://www.kyuzz.org/antirez/papers/dumbscan.html>
(February 25, 2001)
[8]
SanFilippo, Salvatore. "HPING2-HOWTO.txt." August 10, 1999.
[9]
SANS Institute. "Intrusion Detection FAQ." Version 1.42.
URL:
<http://www.sans.org/newlook/resources/IDFAQ/ID_FAQ.htm>
(February 25, 2001)
Links
to Downloadable Source Code
Hping2-Beta54
Source Code - <http://www.kyuzz.org/antirez/hping-src/>
Idlescan-v0.1
Source Code - <http://www.hackers-pt.org/ptstuff/>
TCP
Wrapper Source Code - <ftp://ftp.porcupine.org/pub/security/index.html>